<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>mvvm与mvc开发思想</title>
  </head>
  <body>
    <script>
      /**
       *  
        mvc:
          m: 模型层，数据层
          v: 试图层
          c: 控制器(指的是 页面业务逻辑，根据用户的行为对Model数据进行修改)
          mvc 是单向通信，只能实现 m 到 v 的渲染
          V  ——> C ——> M ——> V
          缺点：一个小的事件操作 都必须经过这样的一个流程(V到C  C到M  M到V) 那么开发就不再便捷

          如果前端没有框架，只使用原生的html+js，MVC模式可以这样理解。将html看成view;js看成 controller。js的ajax可以当做model。
          Model，也就是数据层，通过ajax从服务器获取数据。
          controller：负责处理用户与应用的交互， 响应对view的操作（对事件的监听），调用Model对数据进行操作，
                      完成model与view的同步（根据model的改变，通过选择器对view进行操作）;

        mvvm:
          m:  数据层(model)
          v:  视图层(view)
          vm: 链接 数据层 与 视图层的桥梁。它包含了 DOM Listeners(用于监听操作)和Data Bindings(将数据绑定到试图上显示)

          V ——> <——  VM ——> <—— M 
          VM通过实现一套数据响应式机制自动响应M 层 中的数据变化
          通过VM 会实现一套更新策略自动将数据变化为试图更新
          通过事件监听响应 V 中用户交互修改 M 中的 数据
          这样VM 就较少了大量的DOM 操作代码
          MVVM 在保持 V 和 M 的耦合的同时，还减少了维护他们的关系代码，使用户专注于业务逻辑 兼顾开打效率和可维护性

          mvc 与 mvvm 的区别 并不是vm完全全取代了 c ，vm 存在目的在于处理controller
          中的数据渲染的功能，而不是替代controller，其他操作业务等还是应该放在controller中实现。
          (原来controller中做的事情很多，有业务逻辑，还可能有视图的渲染操作，而现在 vm 更加专注于做业务)这样就实现了业务逻辑组件的重用。
        
        总结：
          1、这两种模式 设计的目的都是为了解决Model 和View 的耦合问题
          2、MVC模式出现较早主要应用在 后端。如Spring MVC 。在前端领域的早期也有运用，
            优点是: 层次清晰。
            缺点：数据流混乱，维护性不好
          3、MVVM 解决了 M V 的耦合问题，VM 层 更加专注做业务，较少了DOM操作，提高了开发效率，可维护性更高

       
       */
    </script>
  </body>
</html>
